New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf(core): avoid recursive scope recalculation when TestBed.overrideModule is used #35454
perf(core): avoid recursive scope recalculation when TestBed.overrideModule is used #35454
Conversation
Additionally, I think the commit message is a bit sparse. It should explain in detail under what circumstances unnecessary recalculation happens, and what's being changed to eliminate it. |
Oh, weird, Github posted my comment twice. |
Per offline discussion:
Approved! |
7f25b33
to
297da72
Compare
…Module is used Currently if TestBed detects that TestBed.overrideModule was used for module X, transitive scopes are recalculated recursively for all modules that X imports and previously calculated data (stored in cache) is ignored. This behavior was introduced in angular#33787 to fix stale transitive scopes issue (cache was not updated if module overrides are present). The perf issue comes from a "diamond" problem, where module X is overridden which imports modules A and B, which both import module C. Under previous logic, module C gets its transitive deps recomputed multiple times, during the recompute for both A and B. For deep graphs and big common/shared modules this can be super costly. This commit updates the logic to recalculate ransitive scopes for the overridden module, while keeping previously calculated scopes of other modules untouched.
297da72
to
4547030
Compare
FYI, Blueprint and Global TAP runs are successful, so marking this PR with "merge" label. |
MERGE ASSISTANCE: this PR is good to go in it's current state (see #35454 (comment)), followup actions will be performed outside of the scope of this PR. Thank you. |
@alxhub I investigated this scenario and it looks like it works as expected and we already have a test that proves it. Thank you. |
…Module is used (#35454) Currently if TestBed detects that TestBed.overrideModule was used for module X, transitive scopes are recalculated recursively for all modules that X imports and previously calculated data (stored in cache) is ignored. This behavior was introduced in #33787 to fix stale transitive scopes issue (cache was not updated if module overrides are present). The perf issue comes from a "diamond" problem, where module X is overridden which imports modules A and B, which both import module C. Under previous logic, module C gets its transitive deps recomputed multiple times, during the recompute for both A and B. For deep graphs and big common/shared modules this can be super costly. This commit updates the logic to recalculate ransitive scopes for the overridden module, while keeping previously calculated scopes of other modules untouched. PR Close #35454
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently if TestBed detects that TestBed.overrideModule was used, transitive scopes are recalculated recursively for all modules and previously calculated data (stored in cache) is ignored. This behavior was introduced in #33787 and causes performance issues in case modules dependency tree is large. This commit updates the logic to avoid unnecessary recursive recalculation in nested modules.
Fixes #35395.
PR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?